昨天我們學了 git fetch，它就像情報員一樣，低調地把遠端最新資訊帶回來，但不會動到你的本地分支。

那如果我們希望「直接同步遠端改動，馬上就能用」呢？

這時候，就要靠今天的主角：git pull。

git pull 是什麼？

你可以把它理解成這個公式：

git pull = git fetch + git merge

也就是說，它會先去遠端抓取更新，然後直接把這些更新合併到你目前所在的分支。

👉 簡單粗暴，一步到位。

基本用法

# 從 origin 的 main 分支抓取更新，並合併到本地
git pull origin main

如果之前已經用 git push -u origin main 建立追蹤關係，那以後只要：

git pull

就能自動拉取對應的遠端分支。

Merge vs Rebase

預設情況下，git pull 使用 merge 合併。這會產生額外的 merge commit，導致歷史看起來比較分叉。

若想要保持歷史乾淨，可以改用 rebase：

git pull --rebase

這樣 Git 會把你的本地提交「重新套用」在遠端分支之上，歷史就會是一條直線。

視覺化比較

Merge（預設）

遠端 main:  A --- B --- C
本地 main:       D --- E

git pull (merge)
結果：
A --- B --- C --- M
             \
              D --- E
M = merge commit

• 保留分叉歷史，產生一個新的 merge commit M。

Rebase（線性歷史）

遠端 main:  A --- B --- C
本地 main:       D --- E

git pull --rebase
結果：
A --- B --- C --- D' --- E'
D', E' = 重新套用的提交

• 把本地提交「疊」到遠端 commit 之後，但 D', E' 是新提交。

小提示

• Merge：適合多人協作，保留合併記錄。
• Rebase：適合保持乾淨歷史，但不要對已推送分支隨意 rebase。

合併衝突處理

有時候遠端和本地的修改衝突，git pull 就會中斷並提示：

CONFLICT (content): Merge conflict in example.txt
Automatic merge failed; fix conflicts and then commit the result.

解決流程：

1. 打開衝突檔案，找到標記：

   <<<<<<< HEAD
   本地內容
   =======
   遠端內容
   >>>>>>> origin/main
   

2. 手動整合正確內容。

3. 標記檔案為已解決：

   git add example.txt
   

   處理完檔案衝突後，使用 git add 標記此檔案已解決。

4. 提交合併完成：

   git commit
   

合併時發生衝突是很正常的，不必慌張。先理解差異，再冷靜解決衝突，就能順利完成合併。

git fetch vs git pull

使用建議

• 開發前先 pull
  → 確保自己基於最新版本工作。
• 怕衝突就 fetch
  → 如果想先觀察更新，建議先 git fetch，再手動決定 merge 或 rebase。
• 配合團隊規範
  → 有些團隊要求 rebase，有些則習慣 merge，請依照專案規則來。

你屬哪一派

• 安全派：

  先 git fetch，再 git log / git diff 看差異，決定要不要合併。

• 效率派：

  直接 git pull，快速同步遠端。

• 乾淨歷史派：

  使用 git pull --rebase，避免產生多餘 merge commit。

小挑戰 💪

1. 修改一個檔案並 commit。
2. 請同事或在另一個 clone 的專案中推送新 commit。
3. 回到本地，使用 git pull 來同步遠端更新。
4. 嘗試用 git pull --rebase，比較歷史紀錄的差異。
5. 刻意製造衝突，練習解決它。

小結

• git pull = git fetch + git merge
• 適合快速同步遠端，但可能會產生 merge commit。
• 若想歷史更乾淨，可用 git pull --rebase。
• 發生衝突時要手動處理，避免覆寫重要改動。

👉 如果說 git fetch 是低調情報員，那 git pull 就是「帶回情報並馬上實施的行動小隊」。